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his  reoort  describes  the  Trio  oneratina  svstem  which  enables 
users  to  simultaneously  develoo  and  execute  programs 
at  three  terminals.  The  svstem  is  written  in  Concurrent  and 
Seouential  Pacal  and  has  been  used  on  a  PDP  11/  55  mini  computer 
since  Sorina  1979. 


The  Trio  Svstem  is  not  available 
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This  research  tested  recent  ideas  on  the  use  of 

abstract  data  types  in  concurrent  programming  by 

implementing  a  multi  terminal  operating  system  for  a 

minicomputer.  This  system,  named  Trio,  was  implemented  in 

Concurrent  Pascal,  a  language  which  makes  it  possible  to 

build  a  large  concurrent  program  out  of  small  modules  that 

can  be  programmed  and  tested  one  at  a  time.  Trio  has  been 

used  by  a  team  of  graduate  students  for  over  one  year.  It 

has  proven  to  be  a  system  that  a  single  person  can 

understand  fully,  depend  on  for  months  without  failure,  and 

« 

adapt  easily  to  changing  requirements.  These  desirable 
properties  of  large  programs  are  the  most  fundamental 
objectives  of  all  work  in  programming  methodology. 

The  research  had  three  major  goals: 

(1)  To  test  the  simplicity  thatp  may  result  from 

using  abstract  data  types  in  the  design  of  realistic 

« 

operating  systems. 

Trio  suprised  its  implementors  by  being  simpler 
than  its  single  user  predecessor  (Solo)  . 

(2)  To  test  how  reliability  can  be  improved  by 
checking  access  rights  to  data  structures  during 
compilation  and  by  testing  operations  on  data  structures 
one  at  a  time. 
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During  the  development  of  Trio,  only  one  error  was 
discovered  that  was  not  caught  by  compile  time  checks  and 
module  tests. 

(3)  To  set  standards  for  the  specification,  design, 
and  documentation  of  non-trivial  concurrent  programs. 

The  following  publications  contain  a  complete 

description  of  the  design  of  Trio: 

Brinch  Hansen,  P.  and  Fellows,  J.,  The  Trio  Operating 
System,  Software  -  Practice  and  Experience  8,  xxxxxxxxx 

Fellows,  J.,  The  Trio  User  Manual.  Computer  Science 
Department,  University  oi  Southern. California, 

Los  Angeles,  CA,  June  1980. 

Fellows,  J.,  Applications  of  Abstract  Data  Types  - 
the  Trio  Operating  System.  Com  pu t  e  r  Sc  i  e nc e  De pa rtm en t , 
University  of  Southern  California,  Los  Angeles,  CA, 

(In  preparation)  . 

The  authors  of  this  report  were  the  only  scientific 
personnel  who  participated  in  this  research. 
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The  Trio  Operating  System* 

PER  BRINCH  HANSEN  AND  JON  FELLOWS 

Computer  Seine t  Department,  University  of  Southern  California,  Lot  Angeles,  California  90007, 

U.SJl. 

SUMMARY 

This  paper  is  u  overview  of  tfao  Trio  lyiun  which  enables  users  to  simultaneously  develop 
and  execute  programs  at  three  terminals.  The  system  consists  of  an  operatln«  system  written 
in  Concurrent  Pascal  and  a  set  of  standard  programs  written  in  Sequential  PascaL  The  system 
has  boon  used  on  a  POP  11/55  minicomputer  since  spring  1979.  This  work  concludes  5  years  of 
— with  tfao  first  abstract  langnhta  for  concnrrsnt  programming. 

kzy  woods  Coocunent  Pssesl  Operstmg  tyscetn  Trio 


BACKGROUND 

This  paper  is  an  overview  of  the  Trio  operating  system  which  enables  users  to 
simultaneously  develop  and  execute  programs  at  three  terminals.  The  system  consists 
of  an  operating  system  written  in  Concurrent  Pascal  and  a  set  of  standard  programs 
written  in  Sequential  Pascal.  The  system  has  been  used  on  the  PDP  1 1/55  minicom¬ 
puter  since  spring  1979. 

This  work  is  a  continuation  of  earlier  work  that  led  to  the  development  and 
implementation  of  the  programming  language  Concurrent  Pascal  which  includes 
processes,  monitors  and  classes. 1 

The  focus  of  this  research  has 'been  the  concept  of  an  abstract  data  type — the 
combination  of  a  data  structure  and  ail  the  possible  operations  on  it  into  s  single 
program  moduli.  This  concspt  contributes  to  simplicity  by  locating  details  of  data 
representation  and  transformation  in  modules  instead  of  spreading  them  throughout  a 
large  program.  It  increases  reliability  by  making  it  possible  for  a  compiler  to  prevent 
data  structures  from  being  destroyed  by  arbitrary  operations. 

So  far  Concurrent  Pascal  has  been  used  to  design  a  single-user  operating  system,  a 
job  stream  system,  a  real-time  scheduler,  and  a  message  passing  system  for  a 
multicomputer  network.2*4  It  has  also  been  used  to  build  several  microcomputer 
operating  systems. 

Each  of  these  model  systems  has  the  following  characteristics: 

1.  Each  concurrent  program  consists  of  modules  of  less  than  one  page  each. 

2.  Each  module  consists  of  a  data  structure  and  a  set  of  procedures  which  can  be 
called  by  other  modules.  These  procedures  provide  the  only  means  of  changing 


*  Tbit  mweh  nt  tuppotted  by  tht  Army  Rmcwch  Oflc*  under  Conflict  No.  DAAG-29-77-G-019L 

0038-0644/80/ 1 1 10-0943801 .00  Rtctivd  21  July  1980 

©  1980  by  John  Wiley  Sc  Sons,  Ltd. 

943 


944 


nit  8JUNCH  HANSEN  AND  JON  FELLOWS 


the  data.  This  protection  of  data  integrity  is  enforced  during  compilation  only  and 
is  not  supported  by  run-time  mechanisms. 

3.  Each  module  can  only  call  the  procedures  defined  within'  a  small  number  of  other 
modules.  The  access  rights  of  modules  to  the  procedures  of  other  modules  are  also 
checked  during  compilation. 

4.  The  modules  are  connected  hierarchically  to  one  another.  So  a  module  cannot  call 
itself  indirectly  through  other  modules.  This  too  is  verified  by  the  compiler. 

5.  The  modules  were  tested  one  at  a  time  from  the  bottom  towards  the  top  (but  may, 
of  course,  be  conceived  top  down).  The  compilation  checks  mentioned  above 
ensure  that  new  (untested)  modules  do  not  make  old  (tested)  modules  fail. 

6.  Each  of  these  programs  was  built  and  described  in  complete  detail  by  a  single 
programmer  in  a  matter  of  weeks. 


The  resulting  systems  have  been  more  reliable  than  the  hardware  they  run  on. 

The  aim  of  the  Trio  system  is  to  demonstrate  the  practicality  of  using  the  same 
programming  concepts  to  build  an  operating  system  of  medium  size.  The  following  is 
only  an  overview  of  the  function  and  structure  of  Trio.  The  reader  is  referred  to  the  user 
manual  for  more  detail.3 

The  Trio  system  is  not  currently  available  for  distribution. 


SYSTEM  OPERATION 

The  Trio  system  is  built  for  a  PDP  11/55  minicomputer  with  80  K  words  of  store,  a 
disk  drive  (of  1  M  words),  a  multiplexor  with  three  alphanumeric  display  terminals,  a 
magnetic  tape  drive  and  a  line  printer. 

The  Trio  system  permits  three  programmers  to  use  the  minicomputer  simul¬ 
taneously.  The  three  users  are  assumed  to  be  members  of  a  (possibly  larger) 
programming  team  which  is  developing  a  set  of  related  programs. 

The  programs  of  a  user  team  are  stored  as  text  and  code  files  on  a  removable  disk 
pack.  The  files  that  are  used  by  the  whole  team  are  described  in  a  single  system  catalog 
on  the  disk,  while  those  that  are  still  being  developed  are  described  in  one  or  more  user 
catalogs.  The  system  does  not  restrict  a  user  to  operate  on  the  files  of  a  single  user 
catalog.  Multiple  user  catalogs  are  provided  to  eni&le  users  to  group  their  files  into 
convenient  subclasses  and  to  operate  on  different  subclasses  simultaneously. 

The  system  is  operated  by  the  users  themselves.  Each  session  typically  lasts  an  hour 
or  more.  At  the  beginning  of  the  session,  the  user  team  mounts  its  own  disk  pack  and 
starts  the  Trio  system.  Each  user  then  sits  down  at  one  of  the  terminals  and  types  a 
command  that  gives  him  access  to  the  files  described  in  a  given  user  catalog  as  well  aa  the 
files  described  in  the  system  catalog. 

A  user  can  now  input,  compile,  edit  and  test  Pascal  programs.  When  a  program  is 
finished,  the  user  can  move  its  description  from  the  given  user  catalog  to  any  other 
catalog  (including  the  system  catalog). 

The  users  can  make  copies  of  text  files  on  the  line  printer.  But  the  system  makes 
display  and  editing  of  text  at  the  terminals  so  convenient  that  die  need  for  printed 
listings  is  reduced  considerably  compared  to  die  Solo  system. 


THS  TWO  O  PIRATING  SYSTEM 


945 


It  is  possible  to  copy  the  files  of  s  single  catalog  (or  the  whole  disk)  onto  magnetic  tape 
and  use  it  to  re-establish  disk  files  after  hardware  or  software  failure. 

The  execution  of  a  program  can  be  pre-empted  by  depressing  the  bell  key  on  a  user 
terminal.  The  system  then  displays  the  line  number  of  the  last  statement  that  was 
executed  in  the  program.  This  is  a  very  convenient  mechanism  for  locating  endless 
loops  in  new  programs  while  they  are  being  tested. 


USER  PROCESSES 

In  the  single-user  operating  system  Solo,  concurrency  could  only  be  exploited  by 
performing  the  input,  execution  and  output  of  a  single  program  simultaneously.  In  the 
Trio  system,  simultaneity  is  achieved  by  the  much  simpler  means  of  executing  three 
user  processes  simultaneously.  No  attempt  is  made  to  perform  the  input/output  and 
program  execution  of  a  single-user  process  concurrently. 

The  concurrent  program  Trio  resides  permanently  in  the  main  store  together  with 
three  user  processes  of  fixed  size.  Each  user  process  serves  a  single  user  terminal. 

A  user  process  executes  a  cyclical  Pascal  program  called  ‘do’  which  accepts 
commands  from  the  corresponding  terminal.  Each  command  specifies  the  execution  of 
a  Pascal  program  with  a  set  of  arguments  of  type  identifier,  integer  or  boolean.  The 
given  program  is  loaded  from  the  disk  and  executed  as  s  procedure  called  by  the  do 
program.  Any  Pascal  program  can  call  any  other  Pascal  program  scored  on  the  disk  by 
means  of  a  standard  procedure  ‘run’  implemented  by  the  operating  system. 

The  operating  system  maintains  a  set  of  booleans  which  represent  the  resources 
shared  by  the  user  processes.  These  resources  are  primarily  the  line  printer,  the 
magnetic  tape  and  the  disk.  A  standard  procedure  enables  a  user  program  to  request 
and  release  exclusive  access  to  any  subset  of  these  resources.  Within  the  operating 
system  these  resources  are  acquired  one  by  one  in  fixed  order  to  prevent  dndlock. 
When  a  user  program  is  pre-empted  by  depressing  the  bell  key,  the  operating  system 
automatically  releases  all  resources  requested  but  not  yet  released  by  the  given  user 
process. 

The  processor  is  treated  as  a  composite  resource  which  consists  of  three  processor 
shares— one  for  each  user  process.  When  a  user  types  a  command  to  the  do  program  the 
latter  requests  exclusive  use  of  the  corresponding  processor  share  before  executing  the 
program  named  by  the  command.  When  that  program  terminates  or  fails,  the  do 
program  temporarily  releases  the  processor  share  again.  When  a  user  wishes  to  execute 
a  concurrent  program  he  needs  exclusive  access  to  the  whole  machine.  This  is  achieved 
by  requesting  the  use  of  all  three  processor  shares — an  action  that  delays  the  execution 
of  the  concurrent  program  until  the  other  user  processes  have  completed  their  current 
execution  of  programs. 

The  interface  between  the  Trio  system  and  any  of  its  user  programs  is  a  set  of 
procedures  that  are  implemented  by  the  operating  system  and  are  called  by  the  user 
programs.  The  names  and  parameter  types  of  these  procedures  are  defined  by  a  piece  of 
text,  called  the  prefix,  which  is  put  in  front  of  every  user  program  before  it  is  compiled. 

These  procedures  give  each  user  program  simultaneous  access  to  at  most  four 
sequential  files.  Two  of  these  files  are  text  files  that  are  read  and  written  character  by 
character.  The  others  are  files  that  are  input  and  output  in  blocks  called  disk  pages. 
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Other  procedures  enable  programs  to  use  the  terminals,  to  create  and  delete  hies  on  the 
disk,  and  to  call  other  programs  stored  on  the  disk.  We  have  tried  to  make  this  interface 
much  more  convenient  to  the  programmer  than  the  interface  of  the  Solo  system. 


FILE  SYSTEM 

The  hie  system  is  the  most  critical  part  of  the  operating  system.  Not  only  is  it  the  long¬ 
term  storage  of  the  users,  but  it  also  resides  on  a  mechanical  device  that  is  several  orders 
of  magnitude  slower  and  much  less  reliable  than  the  computer  itself. 

The  Trio  hie  system  is  an  extension  of  the  Solo  hie  system. 

To  avoid  occasional,  but  time-consuming  relocation  of  data  on  the  disk,  the  pages 
allocated  to  a  single  hie  are  addressed  indirectly  through  a  page  map — a  single  disk  page 
which  defines  the  addresses  of  the  data  pages  of  the  hie.  The  page  map  allows  the 
operating  system  to  place  the  data  pages  anywhere  on  the  disk  and  let  them  remain  there 
until  the  hie  is  deleted. 

The  system  catalog  is  a  hie  that  starts  at  a  fixed  disk  address  and  describes  the  name 
and  attributes  of  all  common  hies  (including  itself).  The  attributes  of  a  hie  are  the  disk 
address  of  its  page  map,  its  protection  status  (true  or  false),  and  its  kind  (scratch,  text, 
code  or  catalog). 

Each  user  catalog  is  described  in  the  system  catalog  as  a  hie  of  type  ‘catalog’.  At  the 
beginning  of  a  terminal  session,  all  hie  names  used  within  a  user  process  are  looked  up 
in  the  system  catalog.  A  user  can  now  select  a  given  user  catalog  by  name.  Following 
this,  all  hie  names  used  by  the  corresponding  process  are  first  looked  up  in  the  given 
user  catalog,  and  (if  that  fails)  they  are  then  looked  up  in  the  system  catalog.  The  set  of 
catalogs  that  are  used  by  a  process  at  any  given  time  is  known  as  its  current  catalog  set. 

A  file  is  opened  by  looking  it  up  in  the  current  catalog  set  and  bringing  its  page  map 
into  the  main  store.  The  file  is  looked  up  by  converting  its  name  to  a  hash  key  that 
defines  the  starting  point  of  a  cyclical  search  in  one  of  thft  catalogs. 

Since  each  user  team  has  its  own  removable  disk  pack  with  a  separate  user  catalog  for 
each  programmer  (or  subtask),  hies  need  only  be  protected  against  accidental 
overwriting  and  deletion.  All  files  are  initially  unprotected.  The  user  protects  a  hie  by 
calling  a  standard  program  which  sets  the  protection  boolean  in  the  hie  attributes  to 
true. 

The  Trio  file  system  then  is  a  hierarchical  system  with  three  levels.  The  first  level  is 
the  system  catalog  which  describes  common  hies  and  user  catalogs.  The  second  level 
consists  of  the  user  catalogs  which  describe  disjoint  classes  of  user  hies.  And  the  third 
level  consists  of  the  user  hies.  Descriptions  of  hies  can  be  moved  freely  from  any  catalog 
to  any  other  catalog.  The  protection  facilities  are  minimal  and  do  not  prevent  users 
from  operating  simultaneously  on  the  same  hies  in  a  time-dependent  manner. 
Although  this  philosophy  is  adequate  for  program  development  from  a  small  number  of 
terminals,  it  is  not  secure  enough  for  .a  general  time-sharing  system. 

We  would  like  to  emphasize  that  since  small  operating  systems  become  inexpensive 
when  they  are  written  in  abstract  programming  languages,  one  can  afford  to  tailor  each 
of  them  for  a  single  purpose.  We  have  followed  this  approach  in  designing  an  operating 
system  that  is  convenient  for  a  computer  with  three  user  terminals.  But  we  have  made 
no  attempts  to  make  the  same  design  applicable  to  larger  systems  with  five  or  ten 
terminals. 
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THE  TWO  OPERATING  SYSTEM 

SIZE  AND  PERFORMANCE 

The  Trio  system  consists  of  a  Concurrent  Pascal  program  and  a  set  of  standard 
programs  of  the  following  lengths: 


Trio  program 

1,600  lines 

Do  program 

500  — 

File  program 

900  — 

Edit  program 

900  — 

Catalog  programs 

2,700  — 

Devica  programs 

1,900  — 

Other  programs 

700  — 

New  programs 

9,200  lines 

Compilers 

17,000  — 

Total  system 

26,200  lines 

The  design  of  the  system  was  started  in  the  spring  of  1978  by  the  authors.  The  initial 
implementation  was  done  over  a  period  of  1  year  by  a  graduate  student  (Jon  Fellows) 
who  was  unfamiliar  with  Concurrent  Pascal  to  begin  with.  During  1979  the  system  was 
used  experimentally  and  tuned.  We  estimate  that  a  full-time  programmer  who  knows 
Concurrent  Pascal  could  have  done  it  in  6-8  months.  By  comparison  Solo  was 
developed  in  3  months. 

The  compilers  for  Concurrent  and  Sequential  Pascal  were  moved  from  the  Solo 
system  with  minimal  changes. 

Trio  requires  a  main  store  of  80  K  words  which  is  used  as  follows: 

Concurrent  Pascal  kernel  4  K  words 

Operating  system  7  K  words 

User  processes  69  K  words 

Main  store  80  K  words 

A  text  file  can  be  created  or  deleted  in  1-2  s  depending  on  its  length  (<128  K  char). 
It  can  be  opened  in  240  ms  and  then  read  or  written  at  the  rate  of  1000  char/s.  The 
overall  performance  of  the  system  for  non-trivial  processing  can  best  be  illustrated  by 
the  compilation  time  which  is  13  s  +  3  ms/ char  for  a  single  user.  When  two  users  are 
compiling  simultaneously,  the  compilation  time  for  each  of  them  becomes 
23  s+5  ms/ char.  The  compilation  time  reaches  35  s+7  ms/ char  when  ail  three  users 
are  compiling  simultaneously  (a  very  unlikely  situation).  This  means  that  the  operating 
system  itself  (of  1600  lines)  can  be  recompiled  in  2-5  min. 

These  execution  times  are  primarily  limited  by  the  speed  of  code  interpretation  and 
to  a  lesser  extent  by  the  slow  disk.  The  compilers  generate  abstract  code  which  is 
interpreted  by  the  well-known  technique  of  ‘threaded  code’. 

FINAL  REMARKS 
In  a  recent  book3  one  of  us  said  this: 

‘The  operating  systems  written  so  far  in  Concurrent  Pascal  are  small.  I 
would  hope  (and  expect)  that  a  larger  system  will  turn  out  to  be  'more  of 
the  same.’  But  it  seems  worthwhile  to  confirm  this  by  using  Concurrent 
Pascal  to  build  a  medium-size  operating  system,  for  example,  a  terminal 
system  that  gives  each  user  the  capability  of  Solo.’ 
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Well,  we  have  done  it  now  and  it  was  more  of  the  same.  The  real  surprise  was  that 
Trio  in  many  ways  turned  out  to  be  simpler  than  Solo!  This  concludes  S  years  of 
experience  with  the  first  abstract  language  for  concurrent  programming.  The 
underlying  concepts  of  processes,  monitors  and  classes  can  now  be  regarded  as  proven 
tools  for  software  engineering.  So  it  is  time  to  do  something  else. 
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